With a growing number of platform level components, reliable board level interconnect testing has become a problem for system manufacturers. OEMs (Original Equipment Manufacturers) have been complaining about the current deficiencies in board level testing and how the companies aren't meeting the needs of the industry. There are reported instances where OEMS threatened component manufacturers to comply with their demand or risk losing their business.
There are several reasons that arcane platform board level testing techniques are untenable going forward for companies. For example, there is a classic problem of checking the electrical integrity of a board without the need for a complete system reset while needing the system to come out of reset to be able to test electrical soundness of a board. However, the board may not come out of reset due to defects introduced in the assembly process. Thus, reset can't be completed, and there is currently an enormous design convergence effort, and time-to-market pressure is preventing companies from making the board testing independent of a full system reset.
Due to the cost reasons (including the additional 4 TAP pins), DRAM logic doesn't incorporate typical board testing logic. OEMs send functional traffic at low speeds, using the board testing apparatus from the CPU. For example, many platform boards include Double Data Rate synchronous dynamic random-access memory (DDR SDRAM) and a DDR board connectivity check involves sending and receiving low speed (<1 MHZ) data via read and write operations between a System-on-Chip (SoC) and the DDR memory. Industry could get away due to relatively lower DDR speeds, but this method is not scalable. DDR can constitute greater than 30% of the overall nets on a typical notebook board. With the increasing DDR speeds and various vendor proprietary logic implementations, some of the DRAMS aren't reliably responding to this traditional way of testing from central processing units (CPUs) at such low speeds. This is creating a test hole and jeopardizing the quality of the platform boards. Thus, DDR training often doesn't occur, preventing one from testing the logic in a functional manner.
Also, there are a number of different types of DRAM that have utilized in the platform and these may each have a protocol associated with them. For example, a particular DRAM may use DDR3 protocol while another uses the DDR4 protocol. The current techniques are not suitable for all these different variants and protocols, which makes performing platform testing difficult.